Many applications and services communicate information over computer networks, such as the Internet, in the form of data packets. Network devices (e.g. routers and switches) process and forward data packets to neighboring network devices in the network according to addressing information contained therein. Logic contained in the network devices is responsible for processing and forwarding received protocol data packets. This logic includes the “forwarding plane” and the “control plane”. The forwarding plane forwards protocol data packets relatively quickly because minimal data processing is performed. Conversely, the control plane forwards data packets (e.g., protocol data packets) much slower because the packets require additional processing (i.e., they must be queued or scheduled) before they are forwarded.
Network devices use routing protocols (e.g., OSPF or IS-IS Hello) to both determine network routes, and to store such routes in local routing tables. Accordingly, upon receipt of a packet, a receiving network device accesses the routing table to determine the route to use for forwarding the packets. During normal error free transmission on a computer network, packets are successfully forwarded and received between network devices. Undesirably, however, interruptions of data flow often occur causing network devices to lose connectivity with neighboring network devices in the network. In response to this problem, routing protocols commonly include “keep-alive” services to detect the loss of connectivity between neighboring network devices. Specifically, keep-alive services typically include “hello” messages that are communicated via the links of neighboring network devices to determine if such neighboring devices are properly operating.
Existing hello messages are typically processed by the control plane and thus, produce a significant communication delay (e.g., from a few seconds to tens of seconds) before a network device is alerted of a loss of connectivity with a neighbor. Such delay often inhibits a network device from recovering from a loss of connectivity, commonly causing data to be lost. For example, many applications and services, such as packetized voice, require notification of a loss of connectivity almost instantaneously (e.g., on the order of less than about 50-200 milliseconds). Accordingly, such a relatively long delay does not adequately provide the intended safeguards of the keep-alive services.